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Abstract — In its recently published TCG Mobile Reference 
Architecture, the TCG Mobile Phone Work Group specifies a 
new concept to enable trust into future mobile devices. For this 
purpose, the TCG devises a trusted mobile platform as a set of 
trusted engines on behalf of different stakeholders supported by 
a physical trust-anchor. In this paper, we present our perception 
on this emerging specification. We propose an approach for the 
practical design and implementation of this concept and how to 
deploy it to a trustworthy operating platform. In particular we 
propose a method for the take-ownership of a device by the user 
and the migration (i.e., portability) of user credentials between 
devices. 

I. Introduction 

As a first deliverable within their scope and work pro- 
gramme, the Mobile Phone Work Group of the Trusted Com- 
puting Group (TCG MPWG) has published a specification [1], 
which offers new potentials for implementing trust in mobile 
computing platforms by introducing a new, hardware-based 
trust anchor for mobile phones and devices. This trust anchor, 
called a Mobile Trusted Module (MTM), has properties and 
features comparable to a Trusted Platform Module (TPM, see 
[2], [3]). Concurrently the MPWG issued a much more uni- 
versal security architecture for mobile phones and devices on 
a higher abstraction level. The pertinent specification is called 
TCG Mobile Reference Architecture (RA) [4] and abstracts a 
trusted mobile platform as a set of tamper resistant trusted 
engines operating on behalf of different stakeholders. This 
architecture offers a high degree on flexibility and modularity 
in design and implementation of the trusted components to all 
participants in hard- and software development. 

An important aspect of the TCG Mobile Reference Ar- 
chitecture is the potential to virtualise significant parts of 
a trusted mobile platform as trusted software applications 
and services. The trusted execution chain for this rests on 
the MTM. The implementation of this chip depends on the 
security requirements of its specific use-case. For high levels 
of protection and isolation, an MTM could be implemented 
as a slightly modified Trusted Platform Module (TPM). This 
enables cost-effective implementation of new security-critical 
applications and various innovative business models, in both 
the mobile and generic computing domain [5]-[7]. 

The present paper discusses the main structural features of 
the RA, highlighting the capabilities of the MTM as the main 
functional building block. After this technology review, we 
propose two basic methods for usage of the RA, namely the 



set-up of a trusted subsystem on a device by a remote owner, 
and its migration from one device to another. 

This paper is organised as follows. In Section 0, we explore 
the significant parts of the MPWG R eferen ce Architecture. It 
is divided into four parts. Subsection II-A gi ves a n overview 
of the security architecture, and subsection 1I-B details the 



concepts of the proposed architectural approach for an MTM 
and the requirements to virtualise its functionality, whereby a 
high security and isolation level is maintained. Furthermore, 
we propose a model for remote stakeholder take-ownership in 
II-C and migration of trusted subsystems in II-D In Section 
[14, we show how such an architecture can be implemented on 
trustworthy operating platforms. 

II. TCG MPWG Reference Architecture 

The TCG MPWG has developed an architecture on a high 
level of abstraction for a trusted mobile platform, which offers 
numerous variations for design and implementation. In this 
section, we reflect essential parts of this architecture and an 
overview of significant platform components in terms of our 
objective. 

A. Architectural Overview 

A trusted mobile platform is characterised as a set of 
multiple tamper-resistant engines, each acting on behalf of a 
different stakeholder. Broadly, such an platform has several 
major components: trusted engines T£ , trusted services TS 
customised by trusted resources T1Z. A general trusted mobile 
platform is illustrated in Figure |l[ 



Tniftteri Engine 




Truster! Engine 

Normal I 
SBrvicss f 



_L 



t 



Trusted 
Resources 









Trufltftd Engine 












Normal I 






Services '1 














Trusted 






San/ices | 






+ 






Trusted 






Re3.pujr«3 | 






4 


r 



Fig. 1. Trusted Mobile Platform Architecture 

We define a trusted subsystem TSS a as a logical unit of 
a trusted engine together with its interrelated hardware com- 
partment. A TSS of a stakeholder a can formally described 



by a tuple 

rSS a = {T£ a ,TS a ,TS e ,T1l a ,SV*,SC a } 

In each trusted subsystem TSS either a remote or local 
entity acts as a stakeholder, who is able to configure its own 
subsystem and define his security policy SV a and system con- 
figuration SC a within an isolated and protected environment. 
The MPWG Reference Architecture specifies the following 
principal entities: the local stakeholders Device Owner DO 
and User U; and the remote stakeholders Device Manufacturer 
DM., and more general Remote Owners 1ZO (e.g. a commu- 
nication carrier, or service provider). The functionality of a 
TSS is either based on dedicated resources of an embedded 
engine T£ a , or may be provided by trusted services TS t of 
external engines. 

Each subsystem is able to enforce its security policy SV a 
and subsystem configuration SC a . As a consequence, the 
functionality of a trusted subsystem TSS a is constrained by 
the available resources T1Z a with their derived trusted services 
TS a , by the offered functionality of external trusted services 
TS e , by the security policy SVa, and finally the system 
configuration SC a of an engine's stakeholder. 

All internal functions executed inside TSS a are isolated 
from other subsystems by the underlying security layer and 
is only accessible if a proper service interface is defined and 
exported. A TSS a relies on the reputation of the stakeholder 
a as basis for that trust. Therefore, each stakeholder issues 
a security policy SV a and a set of credentials belonging 
to embedded trusted components of its subsystem TSS a - 
This policy contains reference measurements (RIM), quality 
assertions and security-critical requirements. 

1 ) Trusted Engines: The most important concept within the 
MPWG Reference Architecture is that of trusted engines. The 
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Fig. 2. Generic Trusted Engine 

purpose of a trusted engine is to provide confidence in all its 
embedded services, which are internally or externally provided 
by the engine. It is a protected entity on behalf of a specific 
stakeholder that has special abilities to manipulate and store 



data, and to provide evidence of its trustworthiness and the 
current state of the engine. Figure ^ shows a generic trusted 
engine. In general, each engine has at least following abilities: 

• implement arbitrary software functionalities as trusted 
and/or normal services, 

• provide the evidence for its trustworthiness, 

• report the evidence of its current state, 

• obtain and use Endorsement Keys (EK) and/or Attestation 
Identity Keys (AIK), 

• access a set of trusted resources, and 

• import and/or export services, shielded capabilities and 
protected functionality. 

In order to establish a definite categorisation, the MPWG 
differentiates engines according to their functional dispensabil- 
ity. Therefore, an engine is either dedicated to a mandatory (of 
DO or DA4) or a discretionary domain (of DO). Engines 
inside a mandatory domain are permanently located on a 
trusted platform and hold security-critical and essential func- 
tionality. All essential services of a trusted mobile platform 
should be located inside the mandatory domain, which does 
not permit a local stakeholder to remove a remote owner from 
the engine. Mandatory engines have access to a Mobile Remote 
owner Trusted Module (MRTM) to guarantee that a valid and 
trustworthy engine state is always present. 

Non-essential engines and services are replaceable by the 
device owner DO and should be located inside the discre- 
tionary domain. Engines inside the discretionary domain are 
controlled by the device owner DO. Discretionary engines 
are required to be supported by a Mobile Local owner Trusted 
Module (MLTM). 

2) Trusted Resources: As illustrated in Figure |[ an internal 
trusted service has access to several trusted resources. The 
TCG calls these resources Root-Of-Trusts (RoT) representing 
the trusted components acting on base of the trusted execution 
chain and providing functionality for measurement, storing, 
reporting, verification and enforcement that affect the trust- 
worthiness of the platform. The following RoTs are defined 
for the mobile domain: 

. Root of Trust for Storage (RTS), 

• Root of Trust for Reporting (RTR), 

• Root of Trust for Measurement (RTM), 

• Root of Trust for Verification (RTV), and 

• Root of Trust for Enforcement (RTE) 

Each RoT vouches its trustworthiness either directly by sup- 
plied secrets (EK, AIK) and associated credentials, which are 
only accessible by authenticated subjects of the stakeholder, 
or indirectly by measurements of other trusted resources. 
These resources are only mutable by authorised entities of 
a stakeholder. 

In this paper, we group several logically self-contained RoTs 
to simplify the presentation of interfaces and the commu- 
nication layer. In a typical arrangement, the RTS and RTR 
represent one unit, while the RTM and RTV build another unit 
within an T SS a . However, note that the RTV and the RTM 
depend on protected storage mechanisms, which are provided 




Fig. 3. Measurement and Verification Process 



by the RTS. Thus, it is also plausible to implement all RoTs 
together as a common unit within an engine. 

RTS/RTR are the trusted resources that are responsible for 
secure storage and reliable reporting of information about the 
state of trusted mobile platform. An RTS provide PCRs and 
protected storage for an engine and stores the measurements 
made by the RTM, cryptographic keys, and security sensitive 
data. An RTR signs the measurements with cryptographic 
signature keys of TSS a . 

RTM/RTV In general, an RTM is a reliable instance to 
measure software components and provide evidence of the 
current state of a trusted engine and its embedded services. 
In the mobile domain, to avoid communication costs, this 
functionality is extended by a local verifier, which checks 
the measurements against a given Reference Integrity Metrics 
(RIM). This process can be done instantly as the measurements 
are performed employing a combination of RTM and RTV. 
Figure [3] depicts such a Measure-^Verify- ^Extend process. 

An RTE is required if an engine uses allocated resources 
and services. In this case, such RoT acts as a trusted boot 
loader and ensures the availability of all allocated trusted 
resources and services within that trusted subsystem. 

3) Services of a Trusted Engine: A trusted engine integrates 
all functionality by customising available platform resources 
as software services. Such a service offers computation, stor- 
age, or communication channels to other internal or external 
services and applications based on dedicated or allocated 
resources. The MPWG categorises them into: trusted, normal, 
and measured services. 

A trusted service customises trusted resources. Thus, a 
trusted service is implicitly supplied with an EK or AIK in 
order to attest its trustworthiness. Trusted services are intended 
to provide reliable measurements of their current state and 
to provide evidence of the state of other normal services or 
resources. 

Normal services are customising normal resources and 
implement functionality, but are not able to provide evidence 
of their trustworthiness by own capabilities. However, normal 
services can access internal trusted services to use their 
provided functionality. Therefore, an internal normal services 



is able to vouch its trustworthiness by associated integrity 
metrics that have been measured by a trusted service. 

B. Mobile Trusted Module 

The generic term Mobile Trusted Module (MTM) refers to 
a dedicated hardware-based trust-anchor. It is typically com- 
posed of an RTS and RTR and has characteristics comparable 
to a TPM. According to their design objective the MPWG 
distinguishes between MRTM and MLTM. Both must support 
a subset of TPM commands as specified in [4]. Additionally, 
an MRTM has to support a set of commands to enable local 
verification and specific mobile device functionality. 

The TCG MPWG Reference Architecture does not exclude 
to utilise a TPM vl.2 (or even a TPM vl.l) as an MTM, 
if an appropriate interface consisting of a set of commands 
conforming to the MPWG specification and associated data 
structures are provided. Although it is possible to implement 
this architecture upon a standard TPM, we here focus on a 
more sophisticated solution based on a Trustworthy Comput- 
ing Platform such as EMSCB/Turaya [8]. In this context, we 
expect three different solutions for isolation, key management 
and protection of TSS a . 

A Standard TPM-based Model uses a non-modified stan- 
dard TPM to build the trusted computing base. The secret 
keys are stored into a single key-hierarchy on behalf of VO 
as specified in [1]. In this case, an adversary or malicious 
local owner may be able to access the secret keys of a remote 
stakeholder and take control of a remote owner compartment. 
A DO can also disable the whole MTM or corrupt mandatory 
engines of remote stakeholders. 

A Software-based MTM-Emulation Model uses a 
software-based allocated AfTAf -emulation with an isolated 
key-hierarchy. All sensitive and security-critical, such as EK 
or SRK, are only protected by software mechanisms outside 
of the tamper-resistant environment of a dedicated MTM [9], 
[10]. 

Generic MTM-based Model supporting multiple stake- 
holders and virtual MTMs. In order to circumvent resulting 
drawbacks and mitigate attacks, we favour a solution with a 
higher level of security. For this reason, we adopt the proposed 
secure co-processor variant of [9] and describe a generic 
MTM with support for multiple stakeholder environments. 
In a cost-efficient scenario, the trusted mobile platform is 
implementable based on a single generic MTM and several 
virtualised MTMs for each trusted engine. Hence, at least 
one dedicated MTM has to be available and additionally a 
unique vMTM has to be instantiated in each trusted subsystem 
TS a . In such case, a physically bounded MTM in the platform 
acts as a master trust anchor and offers MRTM and MLTM 
functionality with respect to its specific use case. 

A Trusted Software Layer offers a vMTM Proxy Service 
to all embedded trusted engines T£ a . The main task of 
this service is to route MTM commands from a T£ a to 
its dedicated instance vMTM a . The advantage is that all 
security-critical MTM commands are tunnelled to vMTM a 
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Fig. 5. Remote Stakeholder Take-Ownership Protocol 



Fig. 4. MTM Architecture supporting multiple Stakeholders 

and are executed within the protected environment of the 
dedicated MTM. 

Figure |] illustrates the architecture of a generic MTM with 
isolated vMTM compartments. This architecture requires a 
slightly modified TPM. Mainly, we add a trusted component, 
the vMTM Instance Manager, which is responsible to separate 
vMTM instances from each other. This includes adminis- 
tration, isolated execution, memory management and access 
control for each stakeholder compartment. Thus, a vMTM 
instance is able to hold an autonomous and hardware-protected 
key hierarchy to store its secrets and protect the execution 
of security-critical data (e.g. signature and encryption algo- 
rithms). 

C. Setup and Take-Ownership of a Trusted Subsystem 

The take-ownership operation establishes the trust rela- 
tionship between a stakeholder and trusted mobile platform. 
Currently, the MPWG Reference Architecture does not define 
how a remote owner is to perform this initial setup and take- 
ownership of its TSS„. Hence we propose a method in this 
section. The main idea behind our procedure is to install and 
instantiate a 'blank' trusted subsystem TSS* containing a 
pristine engine T£^ with a set of generic trusted services 
TS*. This subsystem is then certified by a remote owner, 
if the platform is able to provide evidence of its pristine 
configuration and policy conformance with respect to 1ZO. 
Figure |5] illustrates this process, which we now descirbe. 

Platform and Protocol Precondition. In a preliminary 
stage, the trusted mobile platform has carried out the boot 
process and has loaded the trusted computing base and the 
engine TE-dm with its trusted services. The trusted platform 
has checked that the installed hardware and running software 
are in a trustworthy state and configuration. It is able to report 
and attest this state, if challenged by an authorised entity. 

Remote Stakeholder Take-Ownership Protocol. In the 
first phase, the trusted engine TE-dm carries out a take- 
ownership preparation for the remote stakeholder. A 'blank' 
engine TE*-j_ i s installed and booted by the RTEdm, and 



a clean vMTMhq instance is activated inside the dedicated 
MTM. An initial setup prepares the pristine engine TE^q. A 
endorsement key-pair EK^- LO is generated within vMTM-jio 
with a corresponding certificate Cert-rsSjio 1 ■ 

Next, TS^o performs an attestation of its current state. The 
attestation can be done by the local verifier RTVdm inside 
the TSS dm using RIM certificates of the remote stakeholder 
1ZO. If no suitable RIM and corresponding i?/Af-certificate 
are available for an pristine engine, alternatively a remote 
attestation with an associated Privacy CA is also possible. 

TZ^q creates a symmetric key K-jzo,temp and encrypts 
the public portion of the endorsement key EK^- LO , the cor- 
responding certificate CertrsSno^ attestation and purpose 
information. Next, TS^o encrypts Kno,temp with a public 
key K-jio.pk and sends both messages to the remote owner. 
After reception by the remote stakeholder, the messages are 
decrypted using the private portion of key K-ro.pk- We 
assume that this key is either available through a protected 
communication channel or pre-installed by the device manu- 
facturer. 

In a next step, 1ZO verifies the attestation data and checks 
the intended purpose of TE^o- If the engine and device attes- 
tation data is valid and the intended purpose is acceptable, the 
1ZO generates an individual security policy SVro- The 1ZO 
signs the CertTSSno and creates RIM certificates for local 
verification of a 'complete' TSS a - Furthermore, 1ZO creates a 
Setup Configuration SCtss-ro^ which enforces the engine to 
individualise its services and complete its configuration with 
respect to the intended purpose and given security policy. In 
this step, 1ZO encrypts the messages with the public portion of 
the K-jio,ek and transfers this package to the engine TEro- 

Finally, the trusted engine TE^o decrypts the received 
package and installs it inside the TSS-no and thus completes 
its instantiation. 



'Typically, the key generation needs a so-called Owner Authentication. 
Because this is problematic in a remote-owner scenario, authentication of 
command execution may be enforced by challenge-response mechanisms 
between TZO and TSSjiq. 



D. Migration of a Trusted-Subsystem 

If a stakeholder wants to move a source TSS a ,s to another 
MTM-enabled platform, for instance to port user credentials 
from device to device, all security-critical information includ- 
ing the Storage Root Key (SRK) has to be migrated to the 
target TSSr, t D- In our scenario, we assume the same remote 
owner (e.g. mobile network operator) on both subsystems 
TSS RO ,s and TSS ro ,d- 
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Fig. 6. Trusted Subsystem Migration Protocol 

To be able to securely migrate the SRK, we suggest a 
modification of the current MPWG specification to allow inter- 
stakeholder-migration of a complete isolated key hierarchy. 
Thus, an isolated key hierarchy is (1) migratable between 
environments of identical stakeholders, (2) if and only if an en- 
titling security policy on both platforms exists. The advantage 
of migration between identical stakeholder subsystems is that 
the migration process doesn't require a trusted third party. We 
only involve the owner in combination with local verification 
mechanisms of the TSSro to migrate the trusted subsystem 
(including the SRK) to another platform. This enables for 
instance direct, device-to-device porting of credentials, e.g. us- 
ing short-range communication. We here propose a complete, 
multilateral and secure migration protocol, which is illustrated 
in Figure |[ 

Platform and Protocol Precondition. Similar to section II- 
C, the trusted mobile platform has carried out the same initial 
steps as mentioned above. Furthermore, the remote owner has 
performed an remote take-ownership procedure as described 
in 



II-C 



Trusted Subsystem Migration Protocol. At the beginning 
of the migration protocol, the device owner T>Os of the 
source platform TVs initialises the migration procedure and 
requests an appropriate migration service of TSSro, s- Next, 
the trusted platform TVs is instructed by TSSro to establish 
a secure channel to the target platform TVd- After the 
connection is available, TSSro,s activates the corresponding 
migration service of TSSro, d to perform the import pro- 
cedure. Thereupon, the target subsystem TSS ay D performs 
a local verification of TSSro, S- If revoked, it replies with 
an error message and halts the protocol. Otherwise T£ro,d 
requests an confirmation from the local owner T>Od- 



Next, the target subsystem TSSro, d generates a nonce 
Nro.d- In order to provide evidence of its trustworthiness, 
TSSro. d sends all necessary information to the source 
subsystem TSSro. s- This includes the current state Sro.d, 
a certificate of TSSro, d, security policy SVro,d and the 
nonce Nro.d- Having received the target subsystem's mes- 
sage, TSSro,s verifies the state of TSSro, d- If the target 
system is in a trustworthy state and holds an acceptable 
security policy and system configuration, the current state of 
TSSro,s is locked to nonce Nro,d- 

The TSSro, s generates a symmetric migration key Km, 
serialises its instance and encrypts it with the migration key, 
which is bound to an acceptable configuration of TSSro, d- 
Next, the key-blob and the encrypted instance are sent to the 
destination TSSro, d- In particular, this includes the whole 
isolated key-hierarchy IC-jio.s with SRKno,s, the security 
policy SVro.s, and the required subsystem configuration 
SCro,s- 

Finally, the target subsystem TSSro, d decrypts the re- 
ceived blob and uses SRKro.s as its own SRK. The 
subsystem verifies the obtained security policy SVro,s and 
the subsystem configuration SCro,s- With this information, 
TSSro, d rebuilds the internal structure of the source. 

The source system should then be notified of the success of 
migration and ultimately delete the migrated key hierarchy (or 
even do it before sending the migration package as indicated 
for simplicity in Figure ||). Otherwise one obtains replicated 
trusted subsystems, by themselves indistinguishable to the 
remote owner. But this may depend on the policies to be 
enforced in the particular use case. 

III. Design of Mobile Trusted Modules on 
Trustworthy Operating Platforms 

A prototypical implementation of the trusted engines and 
the specified trusted services was realised as an extension to 
the existing EMSCB / Turaya Computing Platform. Turaya is 
an implementation of the EMSCB security architecture. It pro- 
vides fundamental security mechanisms and a protected and 
isolated execution environment, which meet the requirements 
of the MPWG Reference Architecture [8], [11], [12]. 

Figure [7] illustrates our model, in which a hypervi- 
sor/microkernel executes a legacy operating system in coexis- 
tence with a running instance of the EMSCB-based security 
architecture. The latter controls a virtual machine with several 
trusted engines and services compliant to the MPWG require- 
ments [1], [4]. In the following paragraphs, we outline the 
significant platform layers concerning our approach. 

The Hardware Layer of our model includes a generic 
MTM as described in Section 1I-B, in addition to conventional 



hardware components. This MTM acts as a dedicated master 
trust anchor for the complete trusted mobile platform. 

The Virtualisation Layer provides generic hardware ab- 
straction, between the physical hardware of a trusted mobile 
platform and the Trusted Software Layer below. The EMSCB 
project supports microkernels of the L4-family [14] such as 
hypervisors [15]. In general, all solutions provide mechanisms 




Fig. 7. Trustworthy Operating Platform with multiple Trusted Engines 



for resource management, inter-process-communication (IPC), 
virtual machines, memory management and scheduling. In 
our specific case, the virtualisation layer includes also a 
fully functional device driver for a dedicated generic MTM. 
Furthermore, it is responsible for instantiation of both the 
trusted software layer and the legacy operating system. 

The Trusted Software Layer provides security functional- 
ity and is responsible for isolation of embedded applications 
and software compartments. It also i mplem ents the vMTM 
Proxy Service as described in Section H-B . Currently, EM- 
SCB/Turaya provide an excellent foundation by its security 
services (trust manager, compartment manager, storage man- 
ager), which are required by the RTR and RTV, Protected 
Storage and Trusted Engines Management Agent of TSdm- 
Therefore, it is reasonable to build the significant parts of the 
device manufacturer engine TE dm within this layer. 



Trusted engines TS a within the Application Layer are im- 
plemented as parallel and isolated L4Linux compartments [13] 
on behalf of different stakeholders. Each compartment has 
access to its vMTM instance through an embedded client- 
side device driver. This driver constrains the functionality with 
respect to its specific use case (MRTLM or MLTM). Further- 
more, T£ a has an RTE a , which is responsible for building 
all required allocated trusted resources and services depending 
of its specific system configuration SC a and security policy 
SV a . 



IV. Conclusion and Further Work 

We have introduced the Trusted Engines and MTMs in terms 
of our objective. In this context, we have exposed significant 
parts of the MPWG Reference Architecture and how it can be 
implemented on a (very slightly modified) TPM trust-anchor. 
We have shown how to deploy trusted virtualised compart- 
ments on devices and exhibited basic operations required in 
the mobile domain, such as migration. 

Using a vMTM in lieu of a Subscriber Identity Module 
(SIM) as a trusted and protected software allows expansion to a 
much wider field of authentication and identification manage- 
ment systems even on standard PC platforms [16]. Supporting 
online transactions by authentication via credentials held in 
a vMTM may be one attractive use case. However, there 
are some privacy and security challenges associated with this 
implementation on a desktop computer, which require further 
research. Finally, replacing SIMs/USIMs by multi-purpose 
vSIMs may be attractive even for genuine mobile devices. 
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